A wizard consists of multiple wizard pages that a user progresses through by clicking on the Next or Back buttons. Each wizard page of the wizard provides some information to the user to guide him through a subset of tasks necessary to complete a larger task. Wizards are used very commonly within graphical user interface (hereinafter “GUI”) operating systems and by hundreds of applications that run in these operating systems.
FIG. 1 illustrates an interactive help utility called a wizard 100, which appears as a modal window, within an application. The wizard generates windows that guide a user through each step of a particular task, such as starting up a word processing document in the correct format for a business letter. The GUI window of the wizard 100, like other window applications, includes a title bar 102, which is a horizontal space at the top of a window that contains the name of the window. Appearing as a square button in the right corner of the title bar 102 with an X mark on it is a Close button 104. Clicking on the Close button 104 cancels the wizard 1100. The wizard 100 also includes a number of screens 106, 108, and 110 that present information and receive input (information) from a user during the performance of the task defined by the wizard. The screens 106-110 may be navigated back and forth using a back button 112 or a next button 114. After collecting sufficient information from a user, the wizard 100 presents a Finish button 115. A user clicking the Finish button causes the wizard 100 to proceed to perform the wizard's task. At any point, a user may exit from the wizard 100 by clicking on a Cancel button 116. Clicking on the Cancel button causes the wizard 100 to quit and returns the user to the application that originally invoked the wizard 100.
Traditionally, the process of creating a wizard can be laborious and somewhat tedious. Here are typical development steps: First, the developer creates a main user interface that will host all of the wizard pages of the wizard. Second, the developer creates a user interface for each page of the wizard as well as writes the code to handle each page. Third, the developer has to come up with a mechanism for placing each page onto the main user interface of the wizard. And the mechanism should be cognizant that the presentation of these pages has to be in the correct order. In complicated wizards, the order of the pages might change based upon a user's selections. Thus, the mechanism needs to be able to handle this ordering of the pages. An additional mechanism is created by the developer to allow various pages of the wizard to communicate with one another and pass data back and forth. Then, the developer creates another mechanism for launching and displaying the wizard. And finally, the developer designs a process that launches the wizard and another process to receive the results of users' input from all the wizard pages of the wizard.
This toilsome effort for creating a wizard is repeated anew with each new wizard. Given that many software products make extensive use of wizards, a significant and therefore costly amount of developing time and money is be spent by software manufacturers to develop wizards. One glaring problem is that the conventional approach to create wizards precludes easy reusability of existing components or elements of wizards.
To allow wizard pages of a wizard to communicate with one another and pass data back and forth, each wizard page of a wizard is tightly coupled to a database where data is shared. To use the database, each wizard page of the wizard must intimately know all the data that can be written to or read by the other wizard pages. Otherwise, one wizard page could mistakenly access and change data in the wrong place in the database resulting in the corruption to the rest of the wizard pages of the wizard and possibly detrimental repercussions to the wizard itself. Unfortunately, this requirement results in the data in a database being vulnerably exposed by necessity to all of the wizard pages of the wizard. Not only does this present a serious security problem but it also inhibits reusability. The reason for this is because a wizard designer would have to be intimately familiar with the relationship between data among wizard pages. This familiar intimacy is a time-consuming undertaking, and it may also hinder the efficiency of designing and improving wizards.
All wizard pages of a wizard and their corresponding pieces of code are designed specifically to run without regard to how the pages and corresponding pieces of code can be reused. Conventional wizards are specific to the software products for which they are designed. For example, different software teams within a software company would design different means for transferring data between pages of wizards. Moreover, wizards may look slightly different from one another lacking unity in presentation to consumers. For example, placement of user interface elements, such as title bars, pictures, and buttons, might be differently placed and functions of the user interface elements might diverge from one another.
Thus, there is a need for an architectural software framework for designing wizards that incorporates protocols and means for expansion and interfacing among pages of wizards, as well as a reusable basic programming structure that assists in building wizards, while reducing or avoiding the foregoing and other problems associated with existing wizards.